Development of quality enterprise software, for example, software which is employed by large corporations to conduct operations, is a complicated task. Many organizations have evolved standardized processes for developing software in order to achieve consistency and predictability in their software development activities. This consistency and predictability affect how much time it takes to develop the software and whether the software is robust and reliable.
Typically a software development process produces intermediate products or artifacts along the path to producing the finished software product. Production of these artifacts serves to provide a sense of direction to the software developers. The software developers are instructed about the content and level of detail that the artifacts are expected to contain. Creating the artifact according to these expectations compels the software developer to work through specific issues of the software development and hence defines a sequence and direction to the software development work. The artifacts serve as an excellent basis to share technical information among software developers, testers, and managers. Often the software development process involves reviews of the in-progress software development to decide whether the work has matured sufficiently to advance to the next stage in the software development cycle or whether more work is required.
A variety of names for software artifacts are employed by different companies. Some of the typical artifacts are briefly described below.
Requirements documents define functional requirements that the finished software is expected to satisfy. Sometimes requirements are divided into high level customer requirements and into low level derived or engineering requirements.
Use cases are brief textual descriptions of a business operation at a high level. They are intended to capture the nature of a single business operation from the view of the end user and not the view of the technologist developing the software. Sometimes a hierarchy of use cases may be defined, where a high level use case may be broken down into a number of middle level use cases, and the middle level use cases themselves may be broken into a number of low level use cases. At each lower level in the use case hierarchy, the view of the given use case is narrower and the information captured in the use case is more detailed.
State activity diagrams represent a sequence of activities that a system may perform. The state activity diagram captures a dynamic view of a system, while other artifacts may focus more on a static view of the system. The activities may comprise use cases. Thus, a state activity diagram may relate use cases to each other and capture the logical sequence of the use cases.
Message sequence diagrams, also referred to as sequence diagrams, may be employed to capture inter-module or inter-application communication sessions. These diagrams indicate the participants in the communication session, the senders and the receivers of each communication, the content of each communication, and the sequence of the communications. The communications may be termed messages.
Interface documents define the interface between different modules, systems, or applications. Such documents may define the communication technology employed, for example, sockets, message queues, Java remote method invocation (RMI), transmission control protocol (TCP), and Ethernet. They may define the structure of the information communicated in terms of bit sequences, byte sequences, and fields. They may define the valid values or valid range of values and the meanings of values which may be communicated. They may define a mandatory message sequence, or handshake, for establishing a communication link, for exchanging information, and for terminating the communication link. Sometimes these documents are called interface control documents (ICDs).
High level design documents (HLDs) and low level design documents (LLDs) are comprehensive documents which may contain any of the preceding information. Additionally, HLDs and LLDs typically provide a narrative text description of design. HLDs provide less detail than LLDs. The definition of the type of information belonging in a HLD versus the information belonging in an LLD differs from one software development organization to another. Some software development organizations produce only HLDs and no LLDs. Some software development organizations do not produce either HLDs or LLDs, but capture the information with other artifacts.
Software development tools have been created to aid software developers to develop software and to encourage them to follow and adhere to the corporate software development process. These tools may provide editors for quick construction and revision of message sequence diagrams, interface documents, and other documents. These tools may perform rules checking between development artifacts, for example, to validate that the corporate software development process is adhered to, and to discover shortcomings in a given artifact. Some software development tools may be sold or leased as off-the-shelf software from software vendors. These off-the-shelf software development tools may provide a means to extend their capabilities and to customize their behavior to accommodate the needs of a specific software development organization. Some of these tools may be referred to as computer aided software engineering (CASE) tools.